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A METHOD AND AN ARRA NGEMENT RELATING TO GROUPS OF 
COMMUNICATING USERS 



TECHNICAL FIELD 

The present invention relates to a method and a digital 
telecommunication system where groups of users of 
communication devices exchange information between each 
other. 

BACKGROUND OF THE INVENTION 

Present day telephone systems for conveying messages to 
groups of people and systems for performing simultaneous 
conversations with several people have many 
disadvantages. 

In order to get in touch with, and convey a message to a 
group of people, it is necessary to get in touch by 
making several telephone calls, one to each designated 
person. This is, needless to say, both time-consuming and 
expensive . 

Setting up of so-called conference calls is, in addition 
to being time consuming and costly, also very complex and 
usually calls for a large measure of planning ahead for 
the participants. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to overcome the 
problems as discussed above. This object is achieved by 
inventive systems, methods and computer software 
according to the appended claims. 

The system, which in the following will be denoted as the 
mobile community, offers mobile group communication 
services, enabling groups of people to stay in touch, 
coordinate events and share information anywhere and 
anytime via mobile devices such as mobile phones and 
mobile internet devices. 
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anytime via mobile devices such as mobile phones and 
mobile internet devices. 

The services offered include group voice messaging which 
offers private voice mailboxes that can be accessed and 
5 used by groups of people. When a new message is added, an 
SMS is sent to group members to inform them that they 
should check the group voice mailbox. An e-mail is sent 
to users who do not have a mobile phone. 

Another service offered is group talk which allows users 
10 to talk to each other simultaneously on mobile phones and 
fixed-line phones. When a user wants to initiate a group 
talk session, an SMS is sent to group members to inform 
them that they should call in to join the group talk. 
Another service offered is group text messaging which 
15 allows group messaging via SMS. The sender only needs to 
send a single SMS which is sent to the group members. 
Also a group web service is provided, which includes text 
chat, group contact lists, calendar and information 
lists, such as e.g. recommendations regarding 
20 restaurants, cinemas etc. The group web services are 
accessible via mobile and stationary internet devices 
such as WAP-phones and desktop PC's. 

Groups are created and managed via a web site, and users 
may create and participate in any number of groups with 

2 5 friends, business colleagues, project team members, 

family members, sports club members etc. 

Privacy is obtained through authorization, where each 
member is identified through a user ID and an access 
code. Typically, for mobile phone users, their mobile 

3 0 phone number acts as user ID. 

Groups of users may be either static or. dynamic. Static 
groups are preferably used when a user wants to leave 
messages to, or communicate with, the same people 
regularly. Dynamic groups are used when recipients are 
3 5 unique for each message or call. Dynamic groups exist for 
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one message or call, and are created by selecting 
recipients via the WWW or via telephone. 

Broadcast groups are used for one-to-many communication, 
where one single member, the messenger, is allowed to 
5 leave messages in the group mailbox. Other members can 
read messages and leave responses to the messenger only. 

Advantages obtained with the present invention, Mobile 
Community, include access at any time and anywhere, 
convenience in that a user may communicate with several 

10 people simultaneously via a single phone call. 

Furthermore, cost is reduced, as compared with previously 
known systems, in that the caller only need to pay for a 
single call since recipients call in to the system and 
pay for their calls themselves. The ease of use is also 

15 an advantage, since administration of groups is handled 
via World Wide Web (WWW) pages on a server accessible 
from anywhere via the internet. 

BRIEF DESCRIPTION OF THE FIGURES 

Figure la shows a schematic view of a system according to 
20 the invention. 

Figure lb shows a schematic end-user view of a system 
according to the invention. 

Figure lc shows a schematic administrator view of a 
system according to the invention. 
25 Figure Id shows a schematic view of an application server 
included in a system according to the invention. 
Figure le shows a schematic view of a SM server included 
in a system according to the invention. 

Figure If shows a schematic view of a group talk service 
3 0 included in a system according to the invention. 

Figure lg shows a schematic view of a group message 
service included in a system according to the invention. 
Figure 2a shows a schematic process view of a system 
according to the invention. 
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Figure 2b shows a schematic view of SM server processes 
in a system according to the invention. 

Figure 3a shows a schematic hardware deployment view of a 
system according to the invention. 
5 Figure 3b shows a schematic node configuration view of a 
system according to the invention. 

Figure 3c shows a schematic multiple node configuration 
view of a system according to the invention. 
Figure 4 shows a schematic view of service application 
10 layers in a system according to the invention. 

Figure 5a shows a schematic view of load balancing in a 
system according to the invention. 

Figure 5b shows a schematic view of load balancing in a 
system according to the invention. 
15 Figure 6 shows a schematic view of system interfaces. 
PREFERRED EMBODIMENTS 

For illustrative purposes, the detailed description of . 
the present invention is separated into a number of 
different parts. To begin with, the system architecture 
2 0 of the Mobile Community system will be described. 

Following that, a description of the system interfaces 
with telecommunication networks and service providers. 
Then follows a detailed description of the functions 
performed by the system in use . 

25 The embodiment of the invention will be exemplified in 
connection with cellular telecommunication systems 
adhering to the GSM standard, and hence a number of 
abbreviations will be used that are known to the skilled 
person, and will not be explained in detail. 

30 Nevertheless, some vocabulary, terms, definitions, and 
abbreviations used in this description are as follows: 
Abbreviation Description 

CORBA Common object request broker architecture 

EJB Enterprise Java beans 

35 HTML Hypertext mark-up language 

HTTP Hypertext transport protocol 
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HTTPS 


Secure hypertext transport protocol 




JDBC 


Java database connectivity- 




JSP 


JavaScript pages 




MS 


Mobile station, i.e. a cellular phone. 


5 


MSC 


Mobile switching center. 




ORB 


Object request broker. 




RDBMS 


Relational database management system. 




RUP 


Rational unified process. 




SM 


Short messages . 


10 


SMS 


Short message services. 




SQL 


Standard query language. 




SSL 


Secure sockets layer. 




WRB 


Web request broker. 




WWW 


World-wide web, the Internet. 


15 


XML 


Extended mark-up language. 



The architecture is most easily described using five 
views, which, represent different ways of observing the 
system: a logical view, a process view, a deployment 
view, an implementation view and a use-case view. 

20 The logical view describes the architecturally 

significant parts of the design model, such as its 
decomposition into subsystems, service packages, and 
classes. The process view describes the system's 
decomposition into lightweight processes (single threads 

25 of control) and heavyweight processes (groupings of 

lightweight processes) . The deployment view illustrates 
the configuration and a mapping of processes to each 
processor. The implementation view describes the 
decomposition of the software into layers and subsystems 

30 in the implementation model. Sometimes referred to as 
component view. The use-case view illustrates how the 
software actually works by giving a few selected use 
cases or scenarios. The view also explains how the 
various model elements contribute to the functionality. 

35 The use cases or scenarios given here are chosen because 
they represent some significant, central functionality of 
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the final system, or for their architectural coverage 
(they exercise many architectural elements) or to stress 
or illustrate a specific, delicate point of the 
architecture . 

The logical view 

Figure la illustrates the architecturally significant 
parts of the design model, such as its decomposition into 
subsystems and service packages. For each significant 
package, its decomposition into classes and class 
utilities is described. 

Architecturally significant classes are introduced and 
their responsibilities described, as well as a few very 
important relationships, operations, and attributes. 
Figure 1 shows the major components of the system: End 
User interface components, Administrator interface 
components, Mobile Community services (with web services 
for end users and administrators and community services 
like group talk and group messages) , Network provider for 
SMS services, and SMPT provider, for sending e-mail. 
End user 

As figure lb illustrates, there are four different 
methods of end user - system interaction: WWW browser, 
Mail client, Phone, and Mobile phone. The user uses the 
WWW browser to connect to the system to set up and manage 
his/her profile and communities and the mail client is 
used for different notifications sent from the system. 
A mobile station may receive notification messages (SM) 
from the system via the network providers switching 
center. A mobile phone is used to manage the community 
services like group talks and group messages. A normal 
phone can also be used, like the mobile station, to 
manage the community services. 
Administrator 
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As figure lc illustrates, there are three different 
methods of administrator - system interaction: WWW 
browser, Mail client, and Mobile phone. The administrator 
uses the WWW browser to connect to the system to perform 
system administrative tasks. The mail client and the 
mobile phone are used for different notifications sent 
from the system. 

It shall be noted that the Mobile Community Services 
system will interact with the network provider and the 
SMSC using a secure protocol. 
SMTP provider 

The SMTP provider is a mail server that route mail sent 
from the mail services to users mailboxes on the 
Internet . 

Mobile Community Services (MC services) : 
Web server/Java Server Pages 

The web server handles incoming HTTP requests; retrieves 
information, and sends it back to the client. If the 
HTTP- request is targeted at a JSP (Java Server Page) , the 
request is handed over to the JSP-engine. 
Application server 

As figure Id illustrates, the system runs in an 
application server but no business or data logic is 
implemented as Enterprise Java Beans. The application 
server is used as execution environment for Java Server 
Pages and for the Connection Pool only. 

The application server comprises of the following three 
major components (access layers) : JSP engine (compiler/ - 
executioner) , Business services, Data services, and 
Connection Pool. 
JSP engine 

The JSP engine is a java class that creates a java 
servlet code out of the jsp-code and then compiles it 



W O 00/798 26 



Pa o e 10 of 83 



PCT/SE00/01255 



8 

into a java servlet class. The class code is cached for 
performance . 

The Business services 

Design packets in the business services layer contain 
5 most of the service logic of the system. All access of 
data services from the user services layer is handled 
through the business services layer. 

The following design packets are developed within the 
Mobile Community Services system: crypto, sms, mail, 
10 administrator, alarm, broadcast, community, event, 
grouptalk, invitation, message, news, statistics, 
trafficdata, user, and util . 

Data services 

The data services design packets consists mainly of 
15 components and classes to access entity objects from the 
database. This includes creating new, modifying, and 
removing existing entities as well as searching and 
listing functionality. The packets are not listed here. 
For a complete list of available packets, consult the 
2 0 database design. Examples are: User, Event and 
Invitation. 

Mail services 

The mail services include services for sending email 
(SMTP) . The mail is sent through the SMTP provider. 
2 5 SM services 

As figure le illustrates, the SM server provides 
functionality to send SM to mobile phones from a client 
application in a LAN. The system consists of an SMS 
server that acts as an interface to the network 
30 operator's SMS gateway and a number of SMS clients that 
serve applications with the possibility to send SM 
requests to the SMS server. 

Group talk system 
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As figure If illustrates, the Group Talk System provides 
a service for community groups to join specific group 
calls. The service is available from a mobile phone or a 
normal fixed phone. 

5 The group talk services does not use any of the 

application server functions. The business and data logic 
is called directly from the CT run-time environment 
through a DLL. 

The following functionality is provided within the Group 
10 Talk services: Group call capabilities, Recording voice 
messages, Pre-recorded audio messages for information 
from the system to the user, Touch- tone input for login 
to system, setting up and joining a group call, and Dial 
out enabling the system to make calls to users and play 
15 pre-recorded messages. 

Group message system 

As figure lg illustrates, the Group Message System 
provides a service for community groups to record and 
listen to voice messages located in a message store. The 
20 service is available from a mobile phone or a normal 
fixed phone. 

The group message services does not use any of the 
application server functions. The business and data logic 
is called directly from the CT run-time environment 
25 through a DLL. 

All voice messages is stored as flat binary files in the 
file system of the OS of choice. META-inf ormation about 
recorded messages is stored in the RDBMS. The realisation 
and implementation of this message is store is TBD. 

3 0 The following functionality will be provided within the 
Group Message services :. Recording voice messages, 
Listening to voice messages, Pre-recorded audio messages 
for information from the system to the user, Touch-tone 
input for login to system, recording messages and 

3 5 navigation through system functions/ and Dial out 
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enabling the system to make calls to users and play pre- 
recorded messages 

RDBMS 

All system information, except the recorded voice 
5 messages for the Group Message Services, is stored in a 
relational database (IBM DB2) . Any META information about 
recorded voice messages is also stored in the RDBMS. 
Message store 

All voice messages for the Group Message Services are 
10 stored as flat binary files in the file system of the OS 
of choice. META- information about recorded messages is 
stored in the RDBMS. 

Process view 

This section describes the systems decomposition into 
15 lightweight processes (single threads of control) and 
heavyweight processes (groupings of lightweight 
processes) . Figure 2a shows the major processes and 
groupings thereof in the system. 

Processes 

20 This section describes of the heavyweight processes in 
the system, shown in figure 2a. 
Web server and application server 

The web server and application server is described 
elsewhere . 

25 SM Server 

As figure 2b illustrates, the SM server application 
consists of one permanent lightweight process running the 
administration interface. From the GUI thread a server 
thread is started and stopped. The server thread handles 
3 0 new client connections and administrates the requests. 

The GUI and server threads exchange data mainly by using 
a common instance of a class containing the server 
characteristics . 
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Beside these single threads, there are an arbitrary 
number (upper limit controlled by the server 
administrator) of session threads that are started and 
stopped as clients connect and disconnect . The server 
thread creates the session threads, one for each client 
connection. The session threads take over the client 
connections and execute the requests. As response is 
received from the SMS Gateway and forwarded to the 
client, the session thread stops. 
RDBMS 

All system information, except the recorded voice 
messages for the Group Message Services, is stored in a 
relational database (probably Oracle) . 

Any META information about recorded voice messages is. 
also stored in the RDBMS. 

CT Services 

These are the group message and group talk systems. 
The server (or rather, service) is build on the run- time 
engine of the selected CT-platform and uses the same 
business and data logic as the web application. 
Deployment view 

Figure 3a shows the system's physical network (hardware) 
configuration on which the software is deployed and run. 
The configurations indicate the physical nodes 
(computers, CPUs) that execute the software, and their 
interconnections (bus, LAN, point-to-point, and so on.) 
Included is also a mapping of processes from the process 
view onto physical nodes . 

In detail, the system is described with different 
configurations, called minimum configuration and multiple 
node configuration. 

Figure 3b illustrates a "minimum" configuration, which is 
in reality not a single node due to the two parallel 
systems and the Data server and SMS server. 
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All telephony related services execute in one node and 
the web services, the application server and the SMS 
server execute in the other. Depending on the type of 
toolkit/api used in the phone-related applications, the 
5 phone services may be able to use the application server 
for distributed business objects and access to the RDBMS. 

Phone services server 

The telephony server is equipped with several PRI -cards 
and DCB-cards (for conferencing) . These cards are 
10 connected through a SC-bus for internal communication 
between CT-resources . 

Web services server 

All presentation logic is implemented as Java Server 
Pages (JSP) , handled by the JSP engine installed in the 
15 web server. 

All business and data logic for the web- services is 
implemented as normal Java classes, not EJB. 

In a single node configuration, this node is configured 
with a web server and the application server of choice. 

20 The SMS service may also execute in this server, but 

there is a choice to install and execute this application 
on a separate server. 

Data server 

In the Data server executes the RDBMS. This is also the 
25 server where all messages are stored. 

Multiple-node configuration 

Figure 3c shows a "multiple-node" configuration, where 
the amount of concurrent and registered users demands 
multiple web servers and phone servers. 

3 0 The servers in the multiple node configuration is 
explained below. 

Phone services server 
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Adding another server scales the Phone Services. The 
problem with adding another external node is to expand 
the SC-bus, which connects the PRI and DCB resources. 
Connecting the different computer nodes with an external 
ATM-bus solves this . 

Two computers can be connected directly via ATM, but if 
three or more computers are to be connected, this is best 
done through an ATM-switch. 

Application server 

All business and data logic for the web- services is 
implemented as normal Java classes, not EJB. 

In a multiple node configuration, separate servers are 
used for the application servers. Adding another physical 
server with yet another application server running on it 
scales the business and data logic. The application 
servers handle the scaling and load balancing through AS 
to AS communication. 

Web server 

All presentation logic is implemented as Java Server 
Pages (JSP) , handled by the JSP engine installed in the 
web server. 

Adding yet another physical web server scales the web 
servers. The incoming requests for web resources are 
distributed between the web servers through round-robin 
configuration of the DNS , or by doing a sequentially 
redirecting of the requests through a front-door web 
application. 

All web servers have the same host name, but different 
IP-addresses. The DNS-server that resolves a host name to 
an IP-address does this in "round-robin" order so that 
the requests are distributed to all available web 
servers . 

Database server 



WO 00/7 9 8 26 



Page 16 of 8 3 



PCT/SE00/01255 



14 

In the Mobile Community system, adding another server 
does not scale the database. The database should run on 
such hardware that it could be upgraded with more CPU, 
disks and memory when needed, preferably from the 
5 beginning to avoid minimum downtime because of hardware 
upgrades . 

Message store server 

To scale the message store (where all voice messages are 
stored as files) , more disk space is achieved by adding 
10 yet another physical computer with RAID-disks. 

The MC- system must be aware that more disks have been 
added for the voice files. Changing the system parameters 
(configuration) for the MC-system does this. 

SMS server 

15 This is the node where the SMS server executes. This 

server is able to handle thousands of SMS -requests and 
does not need to be scaled into multiple nodes for the 
MC-system. The SMS server may very well execute in one of 
the application server computers, because of the low 

20 impact on the system resources. 
Implementation view 

Figure 4 shows the decomposition of the software into 
layers and subsystems in the implementation model. 

A number of different layers exist within this project. 
25 All layers will be described below. The picture below 

shows how the different applications are built on top of 
different layers. 

Layer descriptions 

Description of the application layers in the system. 
3 0 Phone users IVR 

The mobile and fixed phone users use an IVR (Interactive 
Voice Response) system to navigate through the different 
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applications and functions available through the phone 
interface . 

CT applications 

The CT applications are running on top of the selected CT 
runtime engine. 

HTML GUI 

The GUI (Graphical User Interface) for web browsers is 
built with HTML (Hypertext Mark-up Language) and served 
through a web server. 

JSP 

The JSP (Java^ Server Pages) handles the presentation 
logic (serving/building HTML) and is responsible for 
instantiating and executing the business logic objects. 
Business and data logic 

The business and data logic is implemented as normal Java 
classes and not as EJB, because of performance and 
because the CT application has problems accessing EJB 
from their run-time environment. 
Size and performance 

Below is a summary of target performance such as 

throughput and response times. 

Scalability 

The Application server should be scalable by hardware. 
For detailed description of scaling, see "Deployment 
view" above. 

Load balancing 

Load balancing can be configured for three services in 
the system: Web servers, Phone servers, and Application 
servers . 

Load balancing of web servers 

As illustrated in figures 5a and 5b, the incoming 
requests for web resources are distributed between the 
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web servers through round-robin configuration of the DNS, 
or by doing a sequentially redirecting of the requests 
through a front -door web application. 

All web servers have the same host name but different IP- 
addresses. The DNS-server that resolves a host name to an 
IP-address does this in "round-robin" order so that the 
requests are distributed to all available web servers. 
All first web requests from a web user goes to one web 
server and is handled by a "front door" application. The 
"front door" redirects the user sequentially to the next 
available web server in the system. All following web 
requests from the user is handled by that server. The web 
servers in this solution must be configured with 
different host names as well as different IP-addresses. 
Load balancing of phone services 

The incoming phone lines are configured according to the 
standard "Line hunting" procedure that distributes the 
incoming calls sequentially to the available PRIs. 

A conference resource handler in the CT-application will 
allocate the conference resources. The conference handler 
will store status information about all conference 
resources in RDBMS. Analysing which device that for the 
moment has most idle conference resources makes the 
selection of conference device. 

Load balancing of application server 
Load balancing is built into the application server 
software. If another application server is installed, 
this is initially configured to be aware of the other 
existing application servers. The load balancing is then 
handled by the software through AS to AS communication. 
Fault Management 

Software and hardware will be monitored by an SNMP fault 
management system. SNMP-agents will be installed for each 
server and hardware device. The agents will monitor the 



WO 00/79826 



Page 19 of 8 3 



WO 00/79826 PCT/SE00/01255 

17 

devices for errors and report to an SNMP management 
application if errors occur. Overload and congestion is 
also to be considered as an error. 

The following hardware devices and software can be 
5 monitored over SNMP. Monitored Hardware includes: PRI- 
boards, Audio Conference boards, Network controller 
boards, CPU-boards and ATM-switch. Monitored Software 
includes: CT- application, Webserver, Application server, 
SM server, RDBMS, and Windows NT. 
10 Failure recovery 

The system is not configured with any fail -over 
functionality. For maximum safety and minimum down-time: 
install multiple network adapters, use double power 
supply units in the servers, all disks should be RAID- 
15 configured for safety (1, 5 or combination), and CT- 

servers shall continue to execute Group Talk and Group 
Message calls even though another CT- server is out of 
service. 

System interfaces 

2 0 Figure 6 illustrates how the system according to the 

present invention interfaces other network elements such 
as an MSC, a local exchange, an SMS-C and the Internet. 

The system connects with the MSC(s) of one GSM operator 
through a number of EURO-ISDN devices (30B+D.) 

2 5 Telephony interfaces 

The Mobile Community service is accessed via one GSM 
number. This number is routed to a number of ISDN PRA 
interfaces (2 Mb, 30 B+D) residing in one or several 
MSCs. The MSC(s) must support line hunting over the full 

3 0 set of PRA lines. The normal initial configuration is 

with 6 PRA. 

Preferably, both incoming calls (to access the Mobile 
Community service) and outgoing calls (to make dial-up 
notifications for Group Talk from the Mobile Community 



WO 00/79826 



PCT/SE00/01255 



18 

system) are used. If outgoing calls are not possible via 
this PRA interface, an alternative is to use ISDN PRA 
lines to the fixed network. 

For outgoing calls, a feature called "time distribution 
5 of dial-out notifications" is available with the Mobile 
Community system. This feature distributes dial-out 
notification calls within a certain group. The time 
difference between calls within a group is 0.5 seconds. 
This is done in order to avoid congestion on the GSM 
10 paging channel within one cell. 

The specification of the interface includes: Euro- ISDN, 
CRC4 activation and no ecco cancellation equipment 
between the MSC and the Mobile Community system. 
This interface is carried between the operators MSC 
15 switch site(s) and the Mobile Community operation center 
via G.703 lines. 

SMS interface 

The Mobile Community system interfaces a Short Message 
service provider via the interface "UCP over TCP/IP". 
2 0 This interface has SSL encryption. The Short Message 

service provider could be the GSM partner, but it is also 
possible to use other service providers in case cross- 
network SMS are not available within the country where 
the system is set up. 

2 5 The SMS originates from a specific server located inside 

the Mobile Community system firewall. A port must be 
opened in the firewall for this communication. The port 
number is configurable. 

The Internet or any leased TCP/IP connection can be used 

3 0 for the communication between Mobile Community system and 

the SMS-C. "SMS queuing" is used to handle SMS load 
peaks . 

Internet interface 
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Internet (WWW) can be used by the Mobile Community system 
users to configure their groups, invite more members, 
create new groups etc. 

Hypertext Transfer Protocol (HTTP) as defined in RFC 2616 
and RFC 2068 is used. 

System functions 

Following is a description of preferred functions of the 
Mobile Community system. The description will use the so- 
called Rational Unified Process (RUP) . RUP is a project 
work model by Rational Corporation. Quality and a secured 
delivery plan are major concerns of the work model. Two 
basic elements of this use case driven work model are the 
actor and the use case. 

Definition of Actor 

An actor instance is someone or something outside the 
system that interacts with the system. An actor type 
defines a set of actor instances, in which each actor 
instance plays the same role in relation to the system. 
Definition of Use case 

A use -case instance is a sequence of transactions a 
system performs that yields an observable result of value 
to a particular actor. A use-case class defines a set of 
use-case instances. 

The following actors have been identified: Administrator, 
Guest, User, and Instant user. 

Administrator 

An administrator is a registered and authenticated person 
that has the privilege to administrate the Mobile 
Community system, or specific parts of the system. Use 
cases involving administrators almost always require 
strong authentication. The preferred method of 
administrator - system interaction IS via a WWW browser. 
Guest 
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A guest is a person who accidentally or determined surfs' 
the Mobile Community web site or calls the system for 
registration. Being a guest seldom requires 
authentication. As a guest registers for member services 
he is upgraded to user actor. There are three different 
preferred methods of guest - system interaction: WWW 
browser, and Mobile or stationary phone User. 
A user is a registered and authenticated person who 
actively uses the member services provided by the Mobile 
Community system. Use cases involving users most often 
requires authentication. There are three different 
preferred methods of user - system interaction: WWW 
browser, and Mobile or stationary phone User. 
Instant user 

An Instant user is a person that is invited to a group 
talk but that is not registered with the system. 
Typically, an instant user is a person that is 
temporarily invited by a user to participate in a group 
talk. Instant users can never initiate their own group 
talks. There is one preferred method of instant user - 
system interaction, that is via a Mobile or stationary 
phone . 

USE CASES 

In this section the required system is identified and 
described. Defining the actors and use cases in the 
system does this. 

Web use cases 

These web use cases are use cases related to functions 
and operations performed at the Internet web site. 
Web Demo 
Actors : Guest . 

Purpose: Demonstrate the member services. 
Web Company Information 
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Actors: Guest. 

Purpose: View company information. 
Web Help 

Actors: Guest, User. 
5 Purpose: Get helpful information and tips. 

Description: It shall be possible to obtain help text on 
most web pages. However, advanced help texts are not 
required. 

Web Register 

10 Actors: Guest. 

Purpose: Register for member services. 

Description: By registering a new user account is created 
within the system. The guest has the possibilities to 
register the following data: 

15 • Name/alias (mandatory) 

• Phone number (not mandatory) 

• Email address (not mandatory) 

• Anonymity (mandatory. The guest has to specify whether 
he shall be "visible" or "invisible" in the public 

20 functions of the system. Default value is visible.) 

• User description (not mandatory, the user may add a 
short description of himself that is shown in other 
users contact lists if the user has chosen to be 
visible as described above) . 

25 The guest is not allowed to register an email address or 
a phone number that already is used in the system by 
another user. 

If he registers a mobile phone number, the system will 
verify, using a random generated access code sent to that 
3 0 specific phone as SMS, that he at least actually' has 
access to the mobile phone he registers. 

If an email address is registered a notification will 
also be sent to that address i.e. this is the only 
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possibility for a user with a non-SMS capable phone to 
get a notification. 

The new user is given a unique member number, which in 
normal cases is the phone number registered. If he elects 
5 not to register phone number, a unique member number is 
to be generated by the system. This is also the case if 
the new user registers a non-SMS capable phone. A 
personal user profile is created describing the provided 
information, privileges, etc of the new user. If he have 
10 received invitations for any communities, he is 
immediately prompted to join them. 
Web Welcome 
Actors: Guest, User. 

Purpose: To gain access to the member services. 
15 Description: This is the web site entry point. Here the 
user may choose to access either register, login, or view 
any of the public information web pages like service 
introduction, demo, or company information. 

For example; http://www.incirco.se 

20 If the user have received invitations for a community by 
email and accessed the web site via an -invitation URL, 
the web page is to show a welcome greeting for the 
invitation. 

Web Login 

25 Actors: User. 

Purpose: User authentication. 

Description: Used to authenticate that only registered 
users gain access to the web site member services. User 
states unique member number and access code. The user 
30 will only be permitted to make a limited number of login 
trials,' then the account will be temporarily blocked. The 
user is upon success transferred to his start page. 
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If the user was registered from the TUI he is forced to 
enter missing data (see section 5.1.8) before he is 
transferred to his start page. 

If the user has created any new communities from the TUI 
5 he is forced to enter a community name (see below) before 
he is transferred to his start page. This is also the 
case if the user has changed name from the TUI since last 
web login. 
My Communities 

10 Actors: User. 

Purpose: A users personal start page. 
Description: 

• Gives the user an overview of the communities in which 
he is a member. 

15 • Informs of new invitations: A list of the user's 
pending invitations will be shown. Next to each 
community there will be a link to click to see more 
details about the invitation, see section 5.1.19. 

• Gives a summation of all community news. 

2 0 For each community the user is member of the degree of 

anonymity is shown (i.e. if details of the personal 
profile are hidden for other members or not) . The 
anonymity degree can be changed using the radio button 
that is assigned to each community. 

25 The "My communities" page contains a string that informs 
the user when he used the system last time. In this 
information it is included whether he used the TUI or web 
interface. 

The user's name is displayed on the web interface. 

3 0 Web Complete User profile 

Actors: User. 

Purpose: To enter missing data if user was registered 
from TUI . 



WO 00/79826 



PCT/SE00/01255 



24 

Description: If the user was registered from a phone 
(fixed or mobile) and it is the first web login after 
registration, a new web page is opened where he is asked 
to give additional missing user data. At a minimum he 
5 should enter his name or alias. The user is not 

transferred to his start page until at least his name or 
alias is given. 

Web Enter Community Name 

Actors: User. 

10 Purpose: To enter the name of a community created via 
TUI . 

Description: If the user has created one or more 
communities since last web login (i.e. community creation 
from the TUI) a new web page is opened where he is asked 

15 to type the names for those communities. This is done at 
first login after the creation and is mandatory. The user 
is not transferred to his start page until a name is 
given. The system does not perform any checks whether the 
community name, entered at web interface, matches the 

20 (Spoken community name. 

Community Administration 
Actors: User. 

Purpose: Enable community administration. 

Description: A web page containing information and access 
25 to community administration functions and operations as 
invitations, community owner, remove the community, leave 
the community, modify description of the community, 
change category of the community and to change name of 
the community. If the community owner chooses to change 
3 0 the name of a community all members of the community is 
notified. The notification is performed in the same way 
as the invitation to the group (but telling the members 
that the current community name is changed) . 
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All the above mentioned functions and operations are 
available only to the community owner but to leave the 
community, which is open to all members. 
Note. Preferably, a user can only see the interface for 
5 the functions and operations that the user is allowed to 
perform. I.e. the functions and operations that are 
assigned to the community owner can only bee seen by the 
community owner. 
My Settings 

10 Actors: User. 

Purpose: View ones own personal profile. 
Description: All user data are shown. 

From this use case it is possible to 

• change anonymity (start of use case Change anonymity) 
15 • change access code (start of use case Web change PIN 

code) 

• update personal data (start of use case Personal data) 

• quit membership (start of use case Quit membership) . 

Change Anonymity 

20 Actors: User. 

Purpose: To change the user's anonymity setting. 
Description: The user gives the possibility to change the 
anonymity setting, i.e. whether he shall be visible ^or 
invisible to other users when these are using the public 

2 5 functions of the system. 

News 

Actors: User. 

Purpose : Gives the user a summary of community news and 
updates . 

3 0 Description: For each community the user can view new 

messages, new members or members who left the community, 
new community owner, if any members have updated their 
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contact info, etc. Each new Group Message or Group Talk 
recording notification is attached with a time stamp. 

Web Create Community 

Actors: User, Guest. 
5 Purpose: Create a new community. 

Description: The user creates a new community by naming 
the community. The person may also choose to assign a 
category to the community and a description of the 
community. The user may invite members by selecting 

10 people from his existing contact list (not possible for a 
guest) or by entering them manually. The invitation shall 
contain the names/alias of other invited persons (users 
or guests) . This is applicable both to the e-mail 
invitation sent out and on the "New invitation" page on 

15 the WEB. 

Another way of inviting members is to send them an 
invitation URL. 

If an invited person (user or guest) hasn't replied to 
the invitation within a predefined number of days (a 

20 system parameter configurable by the system 

administrator) an alert might be sent to the community 
owner. An alert might also be sent to the invited person. 
It is possible to configure these alerts independent of 
each other, e.g. in one implementation of the system both 

25 kinds of alerts might be used, but in another 

implementation, only the alert directed to the community 
owner might be used. 

If the user invites a person with a forbidden number 
(i.e. the user states a number stored in the "Dialing 
3 0 Rules File") the user shall be notified and that 
invitation is cancelled. 

The creating user becomes the "community owner". 

Note. If a guest sets up a group, no invitations will be 
performed until the guest has registered. If the guest 
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leaves the system without having registered the group 
will be removed. 

Invite Members 

Actors: User. 

5 Purpose: Invite others as members of a community. 

Description: The community owner may invite additional 
members to his community by selecting people from his 
contact list or by entering them manually. The invitation 
shall contain the names (or alias) of other invited 
10 persons (users or guests) and the users that already are 
members of the group (these are listed as "member" in the 
invitation) . This is applicable both to the e-mail 
invitation sent out and on the "New invitation" page on 
the WEB. 

15 Another way of inviting members is to send them an 
invitation URL. 

If an invited person (user or guest) hasn't replied to 
the invitation within a predefined number of days (a 
system parameter configurable by the system 

2 0 administrator) an alert might be sent to the community 

owner. An alert might also be sent to the invited person. 
It is possible to configure these alerts independent of 
each other, e.g. in one implementation of the system both 
kinds of alerts might be used, but in another 

25 implementation, only the alert directed to the community 
owner might be used. 

If the user invites a person with a forbidden number 
(i.e. the user states a number stored in the "Dialing 
Rules File") the user shall be notified and that 
30 invitation is cancelled. 

Mass Invitation 

Actor: User 

Purpose: Allow the user to invite many members to a group 
in an efficient way 
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Description: The use case starts when the user select to 
invoke the user interface for "Mass invitation" 
The user selects which persons to invite to the group by 
specifying their e-mail addresses separated by comma or 
5 semicolon (to allow "copy and paste" from e-mail clients) 
in the in built mail function of the system. 
The user can write a message to the recipients of the . 
invitation that will be displayed first in the invitation 
e-mail (followed by a standard description of the 
10 service) . 

The user submits the invitation to the system and all 
recipients will receive the e-mail invitation. 

Web Instant Group 

Actors: User. 

15 Purpose: Allow a user to quickly set up group 

Description: From the web, the user can select from his 
contact list or enter new persons, i.e. instant users, to 
invite them to the group talk. If the user invites a 
person with a forbidden number (i.e. the user states a 

2 0 number stored in the "Dialing Rules File") the user shall 
be notified and that invitation is cancelled. 

The instant group that is created shall be saved in the 
system and the user can initiate a group talk and group 
messages with the participants in the instant group 
25 without having to enter their numbers again. The instant 
group is replaced the next time the user creates a new 
instant group. A user can only have one instant group. 

Web Join Community 

Actors : User 
30 Purpose: Allows a user to join a community. 

Description: The system prompts the user with new 
invitations. The user can then choose to 

• Join (accept) . 
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• Join (accept) but hide details in the personal profile 
to other users in the group (only the first name/alias 
is shown) . 

• Not join (reject) . 

5 The default value is Join. 

For each invitation there is a link to further invitation 
details, see below regarding invitation details. 

Web Invitation Details 

Actors : User 

10 Purpose: Allows a user to view details of an invitation 
to which he is invited. 

Description: For each invitation the names (or alias) of 
other invited users and guests that also is invited to 
that particular community are displayed. If the user is 
15 invited to an existing community, the users that already 
are members are listed as "member" . It is also displayed 
which of the invited persons that has joined the 
community and which that haven't. 

Web Contact List 

2 0 Actors: User.- 

Purpose: Allows the user to create and maintain a list of 
other users . 

Description: A user is given the possibility to store 
contacts in a contact list. The contact list contains 
2 5 other users in the system that manually are added by the 
user according to the Add contact use case, see below. 

For each contact, the contact list consists of the 
following fields: 

• Short Code [digits 1-99] 

30 • Note [text field of 160 characters that are defined by 
the user to describe the contact] 

Description (the contacts own description of himself) 
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• First Name/alias (used to sort the list 
alphabetically) 

• Last Name 

• MSISDN/Member no (Member no if no MSISDN is present) 

• email address 

Only the "Short Code" and the "Note" fields are editable 
by the user. 

Note. Whether the data in the fields of a contact are 
visible or not is dependent of what the contact has 
specified when registered (or when modified the personal 
profile) . 

What actually are shown is specified in the UCR of the 
use case. 

The system is able to maintain a list of up to 999 
contacts per user. The short codes (1-99) can be assigned 
to any of the 999 entries in the contact list. The short 
codes are used to address other users when setting up 
instant groups on the TUI . 

From this use case it is possible to invoke the use 
cases : 

• Add contact 

• Delete contact 

• Generate short code 

• Manually enter short code 

• Delete short code 

• Search contact 

• Modify note 
Add Contact 
Actors: User. 

Purpose: Add someone to be part of my personal contact 
list. Contacts can be used to setting up communities as 



WO 00/79826 



Pag e 33 of 8 3 



PCT/SE00/01255 



31 

well as "Instant groups". 

Description: When a user chooses to add a person to his 
contact list the first thing the system does is to ask 
for the telephone number or member number of the person 
5 he wants to. add. The system then checks whether the 

corresponding contact is already in the list. If not, the 
system searches the database for a matching entry for the 
given number (This is done according to the search 
contact use case) . If an entry is found that matches the 
10 number the user is asked if he wants to add this user to 
the contact list . In case the found contact has chosen to 
hide details the user is informed that some fields of the 
contact are invisible. 

If no entry is found for the given number the use case 
15 Invite Friend To The System Via SMS, see below or Invite 
Friend To The System via Email, see below, (depending on 
if the system searched for a mobile phone number or a 
member number) is invoked. 

The user can also add contacts by selecting other users 
20 that are members of the same communities. 

Invite Friend To The System Via SMS 

Actors : User . 

Purpose: To invite a non-registered person to the system. 
Description: This use case is invoked by the Add contact 
25 use case. The user can invite a person to the system 
without inviting the person to a specific group. 

The system informs that an SMS will be sent to the 
current mobile phone number inviting the receiver of the 
message to the system. The user is further given the 
30 possibility to enter an email address in order to 

additionally send an email invitation. The email is sent 
out (with the user's e-mail address as sender. If the 
user has not specified an email address in his profile he 
can not use this function) . To become a user the invited 
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person need to register using the TUI or WEB interface as 
in the normal case. 

Invite Friend To The System Using Email 
Actors: User. 

5 Purpose: To invite a non-registered person to the system. 
Description: This use case is invoked by the Add contact 
use case. The user can invite a person to the system 
without inviting the person to a specific group. 

This use case is similar to the use case Invite Friend To 
10 The System Via SMS. The difference is that an SMS will 
not be sent and that the user is informed that he must 
specify an email address in order to send the invitation. 
The email invitation is identical to the corresponding 
part in use case Invite Friend To The System Via SMS . 

15 Only users with a registered email address can use this 
function. 

Delete Contact 

Actors : User . 

Purpose: Remove a person from ones contact list. 
2 0 Description: Removing a user from ones personal contact 
list is a permanent action; there is no "wastebasket" . 
The user cannot undo this action. 

Generate Short Code 

Actors: User. 

2 5 Purpose: To assign a short code for a contact in the 
contact list. 

Description: The user can generate a short code to any of 
the contacts in his list by using the function for 
automatic generation of short codes. Lowest available 
30 number is assigned. 

Manually Enter Short Code 

Actors: User. 

Purpose: To enter a short code for a contact in the 
contact list. 
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Description: The user can change short codes manually by 
entering a new short code in the field for "Short Code". 
If the user enters a code that is already used for 
another contact he will be informed by the system that 
5 will give him another recommended number (the lowest 
available number) and show him which contact that is 
currently owning the short code. The user is informed 
that if he still wishes to add the selected short code he 
needs to delete the short code from the existing contact. 
10 Delete Short Code 
Actors: User. 

Purpose: To delete a short code for a contact in the 
contact list. 

Description: If the user chooses to delete a short code 
15 the "Short Code" filed is left empty. The deleted short 
code is then available to assign to another contact. 
Send Group Email 
Actors : User. 

Purpose: Sending Group Email to a community. 

2 0 Description: The user shall be able to send an e-mail 

from the web when he is logged in to the service. 
The e-mail should be sent to all members of the community 
that have registered to the system with an e-mail 
address, Only users that have chosen to have their 
25 profile visible to other users in that community should 
have their addresses displayed to others. The sender's 
name and e-mail address displayed on the sent e-mail 
should be the community member performing the action. 
The user must have an email address registered in order 

3 0 to be able to send a mail, otherwise this function can 

not be used. 

Register On Another Website 
Actors : Guest . 

Purpose: Register and login to the system from another 
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web site. 

Description: The system supports the use of an adaptable 
area with text fields to be filled out by the guest 
(name, e-mail address and mobile number) . The adaptable 
5 area will be placed on partner sites and integrated with 
the content shown on that site. 

Once the fields are filled out and the guest click on the 
"log-in button" the guest is forwarded to the login page 
of the MC system and the user information shall appear in 
10 the correct fields. The guest has to review the 

conditions of membership (or accept without reviewing) 
and submits the registration request to the system. 

International Access 

Actor: User, Guest 
15 Purpose: To get access to all Incirco country specific 
sites . 

Description: The system (in Sweden) contains a .com page 
with links to all other Mobile Community system "Web 
Welcome" sites (see above) in different countries. The 

2 0 guest/user will be directed to the country specific "Web 

Welcome" site by clicking on the link. 

Personal data. 
Actors: User. 

Purpose: Modify ones own personal data. 
25 Description: A user may modify his own personal profile. 

The user may for example elect to change his phone 
number. If the mobile phone number is changed, the user 
will be asked to confirm the new number also as his new 
member number. However, both these changes require an SMS 

3 0 validation using a temporary code in accordance with the 

registration procedure. If the user is a community owner 
and chooses to un-register his mobile phone number he 
must hand over the owner ship to someone else in that 
community. Otherwise the. phone number can not be un- 
3 5 registered. 
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Change Community Owner 
Actors: User. 

Purpose: Change to a new community owner. 
Description: The existing community owner assigns new 
community owner. All community members are then notified 
via the "Member news". Only the users that are registered 
with an SMS capable phone are selectable for taking over 
the community ownership. 

Search Contact 
Actors: User. 

Purpose: To search for a user to add to the contact list. 
Description: The user enters phone number or member 
number of the user he wishes to add to the contact list. 
The system searches in the database for a matching entry. 
If the system finds a corresponding user he is added to 
the contact list. 

Modify Note 

Actors: User. 

Purpose : To update a description of a contact in the 
contact list. 

Description: The user may add an own description to each 
contact in his contact list. This use case addresses how 
a user can add and modify a description of a contact. 
Web Introduction 
Actors: Guest. 

Purpose : Introduce and interest a new user to the member 
services . 

Web Logout 

Actors: User. 

Purpose: Logout from the web site member services. 
Description: Logout is a permanent action; there is no 
"wastebasket" . The user cannot undo this action and is 
transferred to the welcome page. 
Web change PIN code 
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Actors: User. 

Purpose : To change PIN code 

Description: The user may change the PIN code (four digit 
PIN code) after successful login. The user must first 
5 enter the old PIN code, then the new PIN code and finally 
a confirmation of the new PIN code. 
Quit Membership 
Actors: User. 

Purpose: Enables the user to quit the member services. 
10 Description: Quitting is a permanent action; there is no 
"wastebasket" . The user cannot undo this action. 

Mailbox 

Actors: User. 

Purpose: To enable users to view community activities. 

15 Description: The system will log messages and member 

activities . Any user in a community can view the message 
log to see who have sent a message and when, and also 
when other members last time accessed the member services 
and this community. 

20 Member List 
Actors: User. 

Purpose: View list of members in a community. 
Description: The user can view name, email and mobile 
phone number of all members in a community. In addition 
25 to this information, the user can view all rejected 

invitations. The user, in the role of community owner, 
may choose to invite new members or remove members from 
the community. 
Remove Members 

30 Actors: User. 

Purpose: Remove members from a community. 
Description: The community owner. may remove any member 
from "his" community. A message is send to the removed 
members by email (preferred) or SMS. All community 
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members are notified via "Member news". Removing a member 
is a permanent action; there is no "wastebasket " . The 
user cannot undo this action. 

Delete Community 

Actors: User. 

Purpose: To permanently delete a community. 
Description: The community owner may permanently delete 
the whole community. A message is sent to all members by 
email (preferred) or SMS. A recall function is not 
needed. 

Leave Community 
Actors: User. 

Purpose: Remove oneself from a community. 

Description: Any member can remove himself as a member of 
a community. A message is sent to that member by email 
(if he has an email address) and to the community owner. 
All group members are notified via the "Member news". 
Telephony use cases 

The telephony use cases are use cases related to 
functions and operations performed from a mobile or 
stationary phone. 

Phone Register 

Actors: Guest, Instant user. 

Purpose: To gain access to the service from a phone 
(fixed or mobile) . 

Description: A guest or instant user has the possibility 
to join the service without having internet access. This 
use case addresses the case when a guest or instant user 
wants to register from a phone. A guest will get to this 
use case from the Phone login use case. An instant user 
will get to this use case from the Phone welcome instant 
user use case. Then follows a telephone dialog helping 
the person to register. Authentication is performed in 
the same way as in the web register use case . 
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Phone Login 

Actors: User, instant user, guest. 

Purpose: User: To gain access to the telephony member 
services and authenticate user. This will be the entry 
5 point for telephony services. Instant user: To detect the 
A-number and route the instant user welcome use case. 
Guest: To route the guest to the Phone register use case 
Description: Whenever possible, A-number detection is 
used to identify the user (or instant user) and the 
10 access code is then not required. If A-number is unknown, 
the user is asked to provide his member number and access 
code, e.g. using a borrowed (not registered) mobile phone 
is also handled by this use case. 

In case an instant user is detected the use case Phone 
15 welcome instant user is activated, see below. 

In case the user calls from a non-SMS capable phone the 
member number and the access code must be given. 
In case A-number detection failed the person might be a 
guest calling to the system for registration. In that 
20 case the person is given the possibility to register, and 
the Phone register use case is then activated. 

If the user is asked to enter the access code he is 
allowed to make only a limited number of trials if wrong 
access code is given. This holds for both mobile and 

25 fixed phones. If wrong access code is given too many 
times the account is temporarily blocked. 
When the user is logged in, the system will perform a 
check to see whether there are any ongoing group talks. 
The system also checks if the user has a recorded spoken 

30 name or not. If the system determine that the user do not 
have a spoken name he should be asked to record one. The 
name is later used in services using spoken names. If the 
user has any invitations to communities that he hasn't 
joined or declined the system informs about this. 
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The first time the community owner logs on via telephony 
services after having created a new community, he is 
asked to voice record the community name. This is also 
the case if the user has changed the name of the 
5 community on the web user interface. 

If there are any new system messages, these will be 
played. 

The user is also informed if he has been removed from any 
communities. 

10 The use case addresses the case where too many users are 
trying to access the telephony services at the same time 
thus consuming all system hardware and software 
resources. 

Phone Welcome 
15 Actors: User. 

Purpose: Main menu of telephony services. 
Description: The system 

• checks if there are any ongoing group talks 

• checks if there are any new group messages 
2 0 • tells if there is member news 

• guides amongst all telephony functions and operations. 
Phone Welcome Instant User 

Actors: Instant user. 

Purpose: Main menu for an instant user. 

2 5 Description: The system welcomes the instant user to the 

system. If there is an ongoing instant group talk the 
instant user will be directed to this. If there are 
instant group messages the instant user is given the 
possibility to listen to them. The system will also give 

3 0 the instant user the possibility to register. 

Phone Change PIN code 
Actors: User. 

Purpose: To change PIN code 
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Description: The user may change the PIN code (four 
digits) after successful login. The user must first enter 
the old PIN code, then the new PIN code and finally a 
confirmation of the new PIN code. 

5 Phone Join Community 

Actors: User. 

Purpose: Accepting community invitations via phone. 
Description: The system checks whether the user has new 
community invitations that are unanswered. 
10 If there exist such unanswered invitations the user is 
given the choice to join the communities or to decline 
the invitations. The name of the user that has sent the 
invitation and the group name are read out (spoken name) 
for each invitation. 

15 If the user chooses to join the community he is asked to 
specify whether he shall be visible or invisible to other 
users of the community 

If the user neither join nor decline the invitation an 
alert notification is sent to the user reminding him/her 
20 that the invitation isn't replied to. The time delay for 
the alert is configurable by the system administrator. 
Phone Set Up Instant Group 
Actors: User. 

Purpose: Allow a user to quickly set up a non-defined 

25 Group Talk (or Group Message) community. 

Description: From the TUI, the user enters phone 
number /member number of other users and/ or phone number 
of instant users to invite them to a group talk, or group 
message. If the user invites any person from the contact 

30 list with a two-digit code assigned the user can enter 
the code instead of the whole telephone number/member 
number . 

The system guides the user through a number of prompts 
and the user interacts with the system using DTMF 
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commands. If the user invites a person with a forbidden 
number (i.e. the user states a number stored in the 
"Dialing Rules File") the user shall be notified and that 
invitation is cancelled. 

5 The user is given the possibility to review the instant 
group, i.e. the names of the members of the instant group 
are read out, using spoken name. If the group contains 
instant users or if no spoken name is assigned to a user 
the corresponding phone number will be read out instead. 

10 The instant group that is created shall be saved in the 
system and the user can initiate a group talk with the 
participants in the instant group without having to enter 
their numbers again. The instant group created is saved 
in the. system and replaced the next time the user create 

15 a new instant group. A user can only have one instant 
group defined. 

Phone Create Community 

Actors: User. 

Purpose: Creating a community from the Telephone User 

20 Interface. 

Description: Users shall be able to set up new static 
communities via the telephony user interface. This is 
done in the same way as setting up instant groups via the 
telephony user interface. If the user invites a person 

2 5 with a forbidden number (i.e. the user states a number 
stored in the "Dialing Rules File") the user shall be 
notified and that invitation is cancelled. 

The user will be asked to make a recording of the group 
name, and the group will be given a temporary name, 
30 typically a time stamp, that will be displayed on the web 
interface until the name is updated by the user, see 
above . 

If an invited person (user or guest) hasn't replied to 
the invitation within a predefined number of days (a 
35 system parameter configurable by the system 
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administrator) an alert might be sent to the community- 
owner. An alert might also be sent to the invited person. 
It is possible to configure these alerts independent of 
each other, e.g. in one implementation if the system both 
5 kinds of alerts might be used, but in another 

implementation, only the alert directed to the community 
owner might be used. 

Phone Initiate Group Talk 

Actors: User. 

10 Purpose: Allow a user to use Group Talk. 

Description: The user selects any community (or the 
instant group) to invite for Group Talk. The system will 
then initiate an outgoing call to all invited users (or 
instant users) leaving a short message and an email 

15 notification. The out dial message will be at least 25 
sec long, consisting of a repeated message of an 
approximate length of 7-10 seconds repeated continuously 
until the called party hangs up or the time limit (25 
sec) is reached. 

20 The out dial message might contain the name of the user 
initiating the Group Talk and the name of the community 
("spoken name" usage) . What actually is included in the 
message is configurable. If no spoken name is recorded 
for the user the system is "silent" instead of reading 

25 the user's spoken name. For line busy calls a SMS will be 
sent . 

Note! Out dial notifications are not performed to non-SMS 
capable phones! 

Then the Group Talk continues, and while waiting for the 
30 first person to join the call, for example advertisements 
can be played. 

A Group Talk is automatically recorded by the system 
during a limited time. The Group Talk recording may be 
accessed as a standard message later on. The recorded 
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message is automatically deleted after a system set 
predefined time. 

The use case addresses the case where too many users are 
trying to access the Group Talk service at the same time 
5 thus consuming all system hardware and software Group 
Talk resources. 

The use case also addresses the case when the receiving 
part of the out dial is an answering machine . In this 
case the out dial shall be aborted. 

10 Note! An out dial notification is initiated according to 
a special sequence. This scheme is given in the UCR. 
Leave message 
Actors: User. 

Purpose : Send a voice message to group members . 

15 Description: The user selects which group to address. He 
then records the message and ends by pressing the # sign. 
The message is recorded in the Group Message store. An 
SMS notification and an email notification (if the member 
has registered the email address) are automatically sent 

20 to all group members, urging them to call in and listen 
to the message . SMS is however not sent to members that 
still have unchecked messages in that that group. SMS is 
neither sent to users using a non-SMS capable phone. 
These users shall receive an email notification if an 

25 email address is registered. If no email address is 

registered the non-SMS capable phone user will not get 
any notification at all for Group Messages. 
Instant user will not receive any notifications. 

For community messages, the name of the person doing the 
30 recording, and the time, is registered in a message log 
that is accessible from the web site member services. 
Listen To Message 
Actors: User, Instant user. 

Purpose: Listen to Group Message or Group Talk 
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Description: When the user calls in to the service, he is 
notified that there are new group messages and/or group 
talk recordings (the system distinguishes between group 
messages and group talk recordings, i.e. the system 
informs how many recordings of each type that are 
available) . For each recording the corresponding group 
name is read out (this is not the case for Instant group 
messages and recordings of instant group talks. In that 
case the spoken name of the user that set up the instant 
group is read out) . The user/instant user is asked if he 
wants to listen immediately or later. If the user chooses 
to listen immediately he will before the message hear 
information on when it was created (date and time) . If 
the user do not want to listen to the timestamp he can 
press the "#" button and then be directed to the message. 
Having listened to the message, the system will give the 
user the possibility to listen to the status of the 
message, i.e. what other users have listened to the 
message (using spoken name) . Note that this is an option. 
Further, the user has the choice of appending an own 
message to the previous one (note that this is not 
possible to instant group messages and instant group talk 
recordings) . If so, he records the Group Message. An SMS 
notification and an email notification (if the member has 
registered the email address) are automatically sent to 
all group members, urging them to call in and listen to 
the message. 

Each user shall start listening to the first recorded 
message that he hasn't listened to before. The user can 
skip messages and jump to the next recorded message. 
As a person has listened to a message, this is notified 
in the message log so that the initiator of the message 
can see on the web, or listen to on the TUI that the 
message has reached its intended audience. 
Phone Change Name Of Community 
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Actors: User. 

Purpose: Change name of an existing community. 
Description: The user has the possibility to change name 
of any community he has created. The user can not change 
5 name of communities for which he is not the community 
owner. All members of the community are notified. The 
notification is performed in the same way as the 
invitation to the group (but telling the members that the 
current community name is changed) . 

10 Phone Record Spoken Name 

Actors: User. 

Purpose: Record spoken name. 

Description: After having registered the user is prompted 
to record a spoken name. This recording is used later, 
15 when the system needs to present the name of the user 
over the phone interface. 

Phone Personal Settings 

Actors : User . 

Purpose : To change personal settings from the TUI 

2 0 Description: The user can from this use case change some 

of the personal settings. These are: 

• The spoken name 

• The PIN code. 

Phone Quit Membership 

25 Actors: User. 

Purpose: To quit membership from the TUI 

Description: The quitting is permanent. The user cannot 

undo this action. 

Phone Change Anonymity 

3 0 Actors: User. 

Purpose: To change the user's anonymity setting from TUI. 
Description: The user gives the possibility to change the 
anonymity setting, i.e. whether he shall be visible or 
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invisible to other users when these are using the public 
functions of the system. 

Phone Community Administration 

Actors: User. 

Purpose: To administrate communities from the TUI . 
Description: The user can administrate communities from 
this use case. The functions that can be performed is: 

• Change the spoken community names 

• Create community 

• Set up instant group 

• Invite members 

• Leave a community 
Phone Invite Members 
Actors: User. 

Purpose: To invite additional members to a community from 
the TUI. 

Description: The user can invite additional members to an 
existing community. The user must be owner of the 
community. If a user hasn't replied to an invitation 
alerts are sent according to above section regarding 
invitation of members. 

Phone Leave Community 

Actors: User. 

Purpose: To leave a community from the TUI 
Description: The user can leave a community from the TUI. 
If the user is the community owner he must assign a new 
community owner or delete the community. Members of the 
community are informed that the user has left the 
community. 

Join Group Talk 

Actors: User, Instant user. 

Purpose: To join a Group Talk session or an instant group 
talk session. 
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Description: The user may join a Group Talk either 
directly after he has logged in using a phone of from the 
main menu. The instant user may join an instant user 
group talk from the Phone welcome instant user use case 
if there are an instant user group talks for that instant 
user. 

If the user is invited to more than one simultaneously 
ongoing Group Talk sessions, the system will ask which 
one he'd like to join, i.e. "For Footballers, press 1; 
for Dart buddies, press 2." If the user/instant user is 
invited to one or more instant group talk sessions the 
system will read the name of the user that set up the 
current instant group. 
Phone Settings 
Actors: User. 

Purpose: Record group names. 

Description: When the user calls in after having created 
a new community, he is prompted to record the community 
name. This recording is used later, when the system needs 
to present the community name over the phone interface. 
Phone Help 
Actors: User. 

Purpose: Get helpful information and tips. 
Description: It shall be possible to have support and 
guidance read in the phone by entering a certain phone 
key from most phone menus. 

Administrative use cases 

Administrative use cases are functions performed by the 
administrator actor in order to maintain and modify the 
Mobile Community system. 

Admin Welcome 

Actors: Administrator. 

Purpose: To navigate the administrative services. 
Description: This is the administrative web site start 
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page. From here the administrator access the 
administrative functions and operations of the system. 
The administrator can here view a log of administrator 
activities. This log is "read only". In this log it is 
5 displayed who logged in as administrator and when. 

Update Email addresses Rules 

Actors: Administrator. 

Purpose: To update the file containing forbidden email 
addresses. 

10 Description: This use case describes how to update the 

file that contains email addresses that are forbidden to 
send messages to. The administrator can specify specific 
addresses, domain or sub domain names. 

Update Dialing Rules 

15 Actors: Administrator. 

Purpose: To update the file containing forbidden outdial 
numbers . 

Description: This use case describes how to update the 
file that contains telephone numbers that are forbidden 
2 0 to dial. Such numbers are for example international 

numbers, premium rate numbers, emergency numbers etc. The 
administrator can specify numbers as well as number • 
series using wildcards: E.g. 112; 90 000; 071*; 00*. 
Add User 

25 Actors: Administrator. 
Purpose: Add new user. 

Description: This use case describes how to add a new 
user to the system. 

Search Users 

30 Actors: Administrator. 

Purpose: To view all or defined part of registered users. 
Description: The search may be performed using some basic 
search criteria as for example name, email, member 
number, mobile phone number, registration date and reason 
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for blocking. It is possible to sort the output 
alphabetically using system-predefined columns. 
Delete User 

Actors: Administrator. 

Purpose: Delete an existing user. 

Description: This use case describes how an existing user 
may be deleted from the system. When a user that is 
deleted is a community owner the community shall be 
terminated and. the other users in the community shall be 
notified via e-mail. 

Modify User 

Actors: Administrator. 

Purpose: Change the properties and settings of a user 
account . 

Description: This use case describes how user details may 
be modified within the system. 

Any user can be blocked from accessing the member 
services . Once a user with a certain phone number is 
blocked, he will need to apply to the administrator by 
email to be able to register a new membership using the 
same phone number. Reasons for blocking can be: 

• Too many login attempts on web 

• Too many login attempts on TUI 

• Blocked by administrator ( and that case which 
administrator) 

For blocked users it is also displayed when the user was 
blocked. 

System Parameters 

Actors: Administrator. 

Purpose: Manage system parameters. 

Description: Administrators may set and change system 
parameters. Among those parameters are "Max simultaneous 
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users in Group Talk", "How long time a recorded messages 
will be saved" . 

Usage Pattern Statistics 
Actors: Administrator. 
Purpose: Evaluating system usage. 
Description: The administrator can see key data 
concerning the usage pattern of the system services, e.g. 
how many groups different persons initiate, group sizes, 
number of SMS sent compared to traffic generated etc. The 
system logs all logins at the TUI and WEB. For TUI 
accesses it is possible to see the length of each session 
as well as initiated SM and out dials during a session. 
For WEB the length of each session (until logout) is 
logged- if the user leave the site without doing a proper 
log-out it is possible to distinguish that session from 
other sessions. 

Traffic Volume Statistics 
Actors: Administrator. 
Purpose: Billing of operators. 

Description: Total voice traffic as well as total SMS 
traffic during a specified period is presented per 
operator. The administrator is further allowed to access 
and upload the traffic log file from the system. The 
traffic log file contains MSISDN/member number and 
start/stop/duration for each call. 
Administrator Rights 
Actors: Administrator. 

Purpose: Specifying rights to other administrators. 
Description: The "master" administrator can specify what 
rights the other administrators of the system will have. 
Administrator Update WEB 
Actors: Administrator. 

Purpose: To change and update WEB sites, strings in SMS, 
email etc. when the system is running. 
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Description: The administrator with access rights 
(according to what has been set for him in use case 
regarding administrator rights) to update web pages is 
able to change all text content of the site's pages 
5 without interrupting the service. The administrator 
(according to what has been set for him in use case 
regarding administrator rights) can also update the text 
used in Short Messages sent from the system as well as 
standardized e-mail texts sent from the system. 
10 Admin Login 

Actors: Administrator. 

Purpose : To gain access to the administrative services 
and administrator authentication. 

Description: This is the administrative web site entry 
15 point. From here the administrator access the 

administrative functions and operations of the system. 
The administrator is required to enter his/her username 
and password. After successful authentication the 
administrator is transferred to the Admin Welcome page. 

20 For example, http://admin.incirco.com 
Admin Logout 
Actors: Administrator. 

Purpose: To exit the administrative services. 
Description: The actor activates logout function or an 
25 automatic logout by a time-out. After logout the actor is 
redirected to the start page of the administrative web, 
the Admin welcome. 

Admin Help 

Actors: Administrator. 
3 0 Purpose: Get helpful information and tips. 

Description: It shall be possible to obtain help text on 
most administrative web pages. However, advanced help 
texts are not required. It shall also be possible to 
print a quick guide from the web. 
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Add Administrator 

Actors: Administrator. 
Purpose: Add new administrator. 

Description: This use case describes how to add a new 
administrator to the system. 

Search Administrators 

Actors: Administrator. 

Purpose: To view all or defined part of registered 
administrators . 

Description: The search may be performed using some basic 
search criteria as for example name, email, member 
number, mobile phone number, and registration date. It is 
possible to sort the output alphabetically using system- 
predefined columns. 

Delete Administrator 

Actors: Administrator. 

Purpose: Delete an existing administrator. 
Description: This use case describes how an existing 
administrator may be deleted from the system. 
Modify Administrator 
Actors: Administrator. 

Purpose: Change the properties and settings of an 
administrator account. 

Description: This use case describes how administrator 

details, as password, may be modified within the system. 

Add Community 

Actors: Administrator. 

Purpose: Add new community. 

Description: This use case describes how an administrator 
may add a new community to the system for an arbitrary 
user. 



Search Community 
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Actors: Administrator. 

Purpose: To view all or defined part of registered 
communities. 

Description: The search may be performed using some basic 
search criteria as for example name, symbol, and 
registration date. It is possible to sort the output 
alphabetically using system-predefined columns. 
Delete Community 

Actors: Administrator. 

Purpose: Delete an existing community. 

Description: This use case describes how an administrator 
may delete an existing community from the system. 
Modify Community 
Actors: Administrator. 

Purpose: Change the properties and settings of a 
community. 

Description: This use case describes how an administrator 
may modify arbitrary community details within the system. 
An administrator can block any community. Once a 
community is blocked, the community owner will need to 
apply to the administrator by email to be able to reopen 
the community. 

Broadcast Message 
Actors: Administrator. 

Purpose: Inform users of needful things, like system 
updates etc. 

Description: The administrator can send email or voice 
message to all users or to a selected part thereof. 
Alarm Settings 
Actors: Administrator. 
Purpose: Configure alarms. 
Fault Management 
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Actors: Administrator. 

Purpose: Detect errors and inform the system 
administrator. 

Description: A function monitors the hardware and 
software and reports errors to a fault management 
application. 

Further functions 

The following will describe functions that cannot easily 
and understandably be analyzed or described as a use 
case. 

Spoken name 

The system supports the use of spoken name for all users. 
The spoken name is recorded from the TUI at the first 
login to the system using the TUI. 
Detect answering machine 

The system is able to detect an answering machine when 
performing out dials. 

Support for users with a fixed phone only 
The system accepts users without SMS capable phone. For 
members that are users of the system using such a phone 
SM notification is not available as an option. When 
logging in to the system from such a phone A-number 
detection should not be used, i.e. the user have to state 
the member number and the access code . 
Automatic configuration of notifications 
In some countries, it is foreseen that out dial 
notifications might be forbidden or restricted to a 
certain group of users. The system shall be able to 
configure on a per user basis what notification method 
that should be used when a Group Talk is initiated. The 
notification schema per user should be set to a default 
value and can be controlled by the application (i.e. can 
differ per country). The configuration is determined by 



PCT/SE00/01255 



55 

what user data are given when registering, and by the 
country setting. 

Support for instant users 

a) The system supports participation of non-registered 
5 users in Group Talks. The system remembers numbers of 

instant users that has been invited to an instant group 
so that they can be given a separate dialogue when 
entering the system. This feature allows users to invite 
persons that have never heard about the MC system to join 
10 an instant group talk. Out dial notification is performed 
in the same way as for a regular user, the instant user 
will get another notification message though. 

b) When an instant user has participated in a Group Talk 
(and the group talk has been terminated) he should 

15 receive a short message with information about the 
service. 

Access to external directories/use of LDAP directory 
The system supports LDAP for access to external directory 
information. This can be used to synchronize data with 
2 0 other directories and to import data from another user 

directory via LDAP. It is also possible to export data to 
another user directory. An external system is allowed to 
query the MC system for certain information via LDAP. In 
the same way - the MC system is able to query an LDAP 

2 5 directory for user information. The queries are done 

"online". 

By allowing LDAP access directly to the MC system (the MC. 
user register/directory - or even" using LDAP for lookups 
internally in the system) other applications are allowed 

3 0 to integrate into the MC system and benefit from the user 

information that already exists there. Many new 
applications are built around a LDAP directory and using 
a directory within the MC system means that it is 
possible to load those applications schemas into the MC 
3 5 directory. 
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Statistics from WEB access 

The system delivers reports on WEB usage. It is possible 
to detect individual users so that the number of unique 
users can be determined, not only the total number of 
hits. 

SMS-C Interface 

a) The system supports an interface to external SMS-Cs in 
a modular way so that adaptation can be made to interface 
new SMS-Cs without having to redesign the service. 

At least the following interfaces are supported 

• SMPPver 3.3 over TCP/IP 

• SMPP ver 3.3 over X.25 

• UCP over TCP/IP 

• UCP over X.25 

b) The system routes the call to the correct SMS-C by 
identify which operator that is assigned to the current 
user (the operator is stored in the user's record). 
Hence, several protocols are supported in parallel in one 
installation. The information of operator is determined 
by the system by analyzing the phone number entered at 
registration. The system is able to analyze the six first 
digits in the telephone number. At least 16 operators are 
able to be determined. 

This feature allows the system to use multiple SMS-Cs for 
notification 

Support for international versions 

a) The system is built in such as way that it can be 
adapted to the local market without the need for system 
modifications. This is attached to the following issues: 

• Language used on WEB pages 

• Voice prompts 
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• Language/Text used in SM sent out for notification 
purposes 

• Language/Text used in e-mails sent out for 
notification and information purposes 

• Language used in out dial notification. 

• Set up of dialing rules (non-allowed out-dial 
numbers) . 

• ISDN parameters 

• b) Other partners (local) can used to translate the 
system into any language. 

Dialling rules 

The system allows out dial to different number series 
specified in a "Dialing rules" file. If the user with a 
forbidden out dial number has SM capabilities a SM should 
be sent to notify that user. The group talk owner shall 
be notified if all invited users can not be notified. 
Email rules 

The system allows for not sending email to certain 
addresses or domain/ subdomain series which are specified 
in a "Email rules" file. 

Secure access for system administrators 

a) The system supports a secure connection for remote 
login by the administrator. The system requires 
preferably a certificate from the administrator's 
terminal . 

b) In order to keep track of possible unauthorized access 
to the system administrator account, all logins should be 
logged with time and IP address of the person logging in 
as system administrator. 

Alarm handling and monitoring 

The system supports alarm handling via SNMP to a SNMP 
manager (not part of the system) . 



WO 00/79826 



PCT/SE00/01255 



58 

Protection against misuse 

All communication systems can be subject to spam and 
misuse by users or guests. 

a) The system supports a function to limit the amount of 
out dials that are initiated by a certain user (i.e. 
through set up of group talks) and block users that 
exceed such value. The system supports an alarm function 
that will be triggered if a user exceeds a certain number 
of initiated out dials during a 24 hour period. The 
parameters is administered through the system 
administration interface (web) . 

b) The system supports a function to limit the amount of 
SM that are initiated by a certain user (i.e. through 
leaving group messages and by inviting new users) and 
block users that exceed such value. The system supports 
an alarm function that will be triggered if a user 
exceeds a certain number of initiated SM during a 24 -hour 
period. The parameters are administered through the 
system administration interface (web). 

Safety aspects 

a) The system preferably uses a PIN code for 
authentication on the WEB interface and on the TUI 
interface. 

b) The system keeps a log of all accounts temporary 
blocked due to failed logon, and shall send an alarm upon 
high volumes of temporary blocked accounts. The system 
shall also send an alarm if an account is blocked more 
than 2 0 times during a period of 1 week. 

c) When logging out from the system, the webpages should 
preferably not be allowed to be cached in the browser 

d) UserlD and password shall preferably not be allowed to 
be handled as part of an URL. 

e) All entry fields on the website must have "Boundary 
checks" to ensure that the indata is of desired type. 
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This checking should be done in the browser. (Otherwise 
there is a risk for e.g.: one can append a 20 MB file in 
one entry field, making the system crash etc.) Boundary 
checks must be done on entries between the webserver and 
the application server in order to prevent unwanted 
database accesses. 

f) The password is preferably encrypted in the browser 
using MD5 or SHA-1.0 before it is sent from the browser 
to the system. 

Max Group Size per User Basis. 

The system is prepared for future assignment of a maximum 
size of community on a user basis. 

Dynamic text usage 

a) It is possible to change web texts without service 
interruption. The content of the WEB pages is stored so 
that the text in the pages can be updated separated from 
the Java Server Pages (jsp) . Access to the text is an 
attribute in the administrator's access rights, i.e. it 
is possible to restrict access to changing the texts to 
certain administrators. 

b) It is possible to change text used in SMs without 
service interruption. 

c) It is possible to change text used in e-mails without 
service interruption. 

Browser compatibility 

The system supports at least America Online 's Netscape 
Navigator 4.05 and later versions and MS Explorer 4.01 
and later versions. 

Multiple message stores and user registers 
The scale the system, the system is designed to allow 
configurations with multiple messages stores distributed 
on several physical servers, and user registers (DB2) 
distributed on several physical servers . . 
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Speech Recognition and Text to Speech 

a) The system is prepared for supporting speech 
recognition. Preferably, it shall be possible for the 
user to assign a spoken name for the persons that the 
user has put in the contact list. 

b) The system is prepared for Text to Speech translation. 
It is preferably be possible to e.g. read incoming emails 
in the TUI . 

Security on ISDN lines 

Should the ISDN lines to the CT- servers happen to carry 
Incoming TCP/IP traffic, the CT-servers shall reject this 
call. 

Auto-maintenance of log-files, user register and message 
store 

a) The database should preferably be cleaned regularly to 
ensure that all obsolete data is removed. 

b) Saved data on system usage (e.g. traffic logs etc.) 
should preferably be automatically archived after e.g. 
three months storage [system parameter] (and thus removed 
from the system) . 

c) It is possible to automatically remove users that have 
been inactive for more than x months (x is a system 
parameter - default value 12 months) . 

Supervision of CT resources 

The system generates SNMP traps if there is any 
degradation in the capacity of the telephony interface. 
The CT resources (SW processes and HW (Line cards, ATM 
cards, Conference cards and servers) ) should be possible 
to poll for status information. The system monitors 
activity on the line cards to ensure that they are 
working properly. If no activity has been detected during 
a certain time (system parameter) the system generates an 
alarm. 
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Capacity - typical numbers without restricting the scope 
of the invention: 

a. The system is capable of meeting a subscriber load of 
2 000 000 subscribers. 

b. The system supports 1000 simultaneous users on the 
web. 

c. The system supports 2000 simultaneous users on the 
TUI. 

d. The system supports full load on 120 ISDN channels and 
one DCB960 conference board in one NT server with the 
following configuration: 

IBM Netfinity 5000 with 1 PHI 677 MHz processor, 256 MB 
RAM. 

Database possible to update 

The database isdesigned in a way so that it is possible 
to update the attributes connected to each user record 
(i.e. it is be possible to add information such as 
address and other user-unique data to each user record) . 
Acoustic profile 

The system uses an acoustic profile. This means that 
different signals will be used to inform the user about 
different events. The following different sounds may be 
used: 

• Group talk has started 

• New Group message 

• Group message (old) 

• Group Talk (recorded) 

• Waiting signal (while group talk is initiated) 

• User enters the group talk' 

• User leaves the group talk 
Latency 
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As a measurement for the quality of service the system is 
designed in such a way that the user never need to wait 
more than 1 second after he has initiate a comment until 
the system answers back. The system is equipped with a 
5 time-out prompt that is played in case the 1 second 

threshold is exceeded during moments of extreme load "The 
system is retrieving data, please wait" or equivalent. 

Sound quality 

There is no "distorted sounds" when playing any speech 
10 prompt. 

Background: GSM uses inband signalling to send DTFM 
signals. This makes the speech channel sound corrupted 
during about one second after a key is pressed. 
Audio codec use 

15 The system is capable of being configured to use 
different audio codecs (supported by the dialogic 
boards) . It shall be possible to use different codecs for 
recording of group talk and group message (which implies 
that the system is able to switch audio codec during a 

20 call. 

Key ahead on TUI 

All menus that allows the user to make a choice support 
key-ahead, i.e. it is possible to choose action without 
having to listen to the prompt to be completed. 



25 
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CLAIMS 

1. A communication system comprising means for enabling 
exchange information between users of communication 
devices in at least one digital communication network, 

5 the devices comprising mobile communication stations, the 
system comprising: 

- means for creating a group with members comprising 
a plurality of the users, 

- means for storing an incoming information message 
10 from a user of a communication device, 

- means for alerting at least a subset of the 
members that an information message is available. 

2. A system according to claim 1, comprising: 

- means for enabling alerted users to access a 
15 stored message. 

3. A system according to any one of claims 1-2, where the 
means for creating a group comprises WWW-interf ace means. 

4. A system according to any one of claims 1-3, where the 
means for creating a group comprises means for creating a 

2 0 group of users originating from different communication 

networks. 

5. A method for enabling exchange information between 
users of communication devices in at least one digital 
communication network, the devices comprising mobile 

25 communication stations, the system comprising steps of: 

- creating a group with members comprising a 
plurality of the users, 

- storing an incoming information message from a 
user of a communication device, 

3 0 - alerting at least a subset of the members that an 

information message is available. 

6. A method according to.' claim 5, comprising: 

- enabling alerted users to access a stored message. 
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7. A method according to any one of claims 5-6, where 
creating a group comprises interaction via WWW- interface 
means . 

8. A method according to any one of claims 5-7, where 
creating a group comprises creating a group of users 
originating from different communication networks. 

9. A computer software product comprising instructions 
for a computer system to perform the steps according to 
any one of claims 5-8. 

10. A method of enabling exchange information between 
users of communication devices in a digital communication 
network, the devices comprising mobile communication 
stations, the method comprising steps of: 

- creating a group with members comprising a 
plurality of the users, 

- distributing information messages originating from 
at least one member of the group to other members of the 
group , 

- providing simultaneous connections between members 
of the group. 

11 . A computer software product comprising instructions 
for a computer system to perform the steps according to 
claim 10. 

12. A communication system comprising means for enabling 
exchange information between users of communication 
devices in a digital communication network, the devices 
comprising mobile communication stations, comprising: 

- means for creating a group with members comprising 
a plurality of the users, 

- means for distributing information messages 
originating from at least one member of the group to 
other members of the group, 

- means for providing simultaneous connections 
between members of the group. 
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